The present invention relates to application support in a data processing system.
In distributed computing environments today, an increasingly large number of distributed applications, (that is to say user programs), are developed using a number of pre-existing applications and may run over an extended period of time. There is a need for systems to support these long-running applications for several reasons. One reason is that the long-running applications may be cumbersome, having complex structures and complex inter-relationships between the constituent applications. Additionally, because the applications often take a long time to complete they may remain inactive for long periods, whilst awaiting user interactions. These long-running applications may also require support for fault tolerance if machines fail or if services are moved or withdrawn.
An example of a distributed environment in which the long-running applications may run is shown in FIG. 1. A client/server data processing apparatus (100) is connected to other client/server data processing apparatus (120) and (130) via a network (110), which could be, for example, the Internet. The client/servers (100), (120) and (130) interact with each other, in the preferred embodiment, to carry out work, such as the processing of transactions (for example, transactions to update bank accounts). Client/server (100) has a processor (101) for executing programs that control the operation of the client/server (100). Client/server (100) also has a RAM volatile memory element (102), a non-volatile memory (103), and a network connector (104) for use in interfacing with the network (110) for communication with the other client/servers (120, 130).
Although each client/server in FIG. 1 is capable of sending and receiving messages from the network, whether they behave as a client and/or servers will depend on the programs that are used to control their operation. These programs can often run several processes on each client/server and these processes can be client or server processes. As a result it is possible for a client/server data processing apparatus to run several processes some of which behave as clients on the network and others that behave as servers on the network
Referring to FIG. 2, a long-running application (200) may also be developed by utilising a number of individual transactions (210-260) running in series or in parallel. Transactions may be nested, whereby one transaction (a child) may be nested within another transaction (the parent). A top-level or root transaction is one that does not participate in nesting.
A transaction is a sequence of co-ordinated operations on system resources such that either all of the changes take effect or none of them does. The coordinated operations are typically changes made to data held in storage in the transaction processing system, system resources include databases, data tables, files, data records and so on. This characteristic of a transaction being accomplished as a whole, or not at all, is also known as atomicity (A). A transaction is also consistent (C) and this characteristic falls under the responsibility of the application. A transaction is also carried out in isolation (I) via locking mechanisms and is durable (D), in that the effects of a transaction must be evident and persistent. These characteristics are often known as the xe2x80x98ACIDxe2x80x99 properties of an individual transaction.
Alternatively, a long-running application may comprise a number of individual activities at arbitrary points during its lifetime. Referring to FIG. 3, an application (300) may also comprise a combination of transactions (315,320) and activities (305,310). An activity is a single unit of distributed work that encompasses a particular piece of logic. An activity may have transactional or non-transactional behaviour during its lifetime and furthermore, a number of activities may be nested in a hierarchy, whereby a nested activity is a child of a parent activity.
Referring to FIG. 4, a series of connected activities (430,435,440,445,450) co-operating during an application""s (425) lifetime is shown. A first activity (430) utilises two top-level transactions (432,434) during its execution. A second activity (440) comprises a transaction (441) and additionally comprises a nested activity (442). The nested activity (442) further comprises a transaction (443).
The structuring of applications as several short-duration transactions, rather than as a single top-level transaction has many advantages. One advantage is that the application acquires and uses resources for only the required duration, rather than for the entire duration of that application.
However, current problems with application structuring mechanisms include the fact that when an application comprising a number of individual transactions is executed, there may be a requirement for the application to possess some or all of the ACID properties not normally associated with the application. However, the process to enable the application to possess some or all of these ACID properties currently involves a manual overhead, whereby a programmer builds application-specific mechanisms.
Additionally, if failures or concurrent access occurs during the lifetime of the application, then the behaviour of the entire logical long-running application may not possess the ACID properties. Some form of application-specific compensation is therefore required to attempt to return the state of the system to application-specific consistency. For example, compensation transactions, which perform forward or backward recovery in order to obtain transactional semantics for the entire long-running application, may be required.
One solution to these problems is the low-level architecture, described by the OMG xe2x80x9cActivity Servicexe2x80x9d. Further information on the Activity Service can be found in the document xe2x80x9cAdditional Structuring Mechanisms for the OTS Specificationxe2x80x9d, by IBM et al, 2000 available at http://www.omg.org. (IBM is a registered trademark of International Business Machines Corporation.)
The Activity Service is an object framework, upon which high-level services can be constructed to represent a variety of extended transaction models that may then support more complex transactional semantics than the simple ACID properties. Referring to FIG. 5, the Activity Service (500) provides support for high-level services (510,520) which can be built on top of it, whereby a high-level service (510) is utilised by an application. An OTS (530) may or may not be built on top of the Activity Service. An activity can therefore represent a particular high-level service or a transaction.
One main component of the Activity Service is a xe2x80x9ccontextxe2x80x9d. A context, in terms of activities, is activity information associated with a specific thread. An activity performing an operation does so within its context and since activities can be nested, contexts can also be nested. Another component in the Activity Service is a xe2x80x9cpropertyxe2x80x9d, which represents application-specific information. A xe2x80x9cProperty Groupxe2x80x9d is a tuple-space of attribute-value pairs for specifying application-specific data.
The current activity service model provides useful functions for the high-level services, such as context demarcation and context propagation. The Activity Service provides general support for demarcation of work that can span multiple ACID transactions and for managing application-specified context data that is made globally available within that demarcation scope. It provides interfaces to specify demarcation boundaries for units of activity, and provides a distributed service context that is implicitly propagated, via an ORB, on remote requests.
Propagation will now be described in more detail with reference to FIG. 6. Multiple threads may be associated with a single activity at any one same time. The multiple threads may be present in the same execution environment or in multiple execution environments. In an Activity Service that is distributed across multiple nodes, activities are also distributed and are implicitly propagated with remote requests.
In FIG. 6, activity context (620) and property group data (610) are associated with an activity (600) on thread 1. At xe2x80x9cAxe2x80x9d, an Activity Service Implementation in Process 1 collects the activity context (620) and property group data (610) into an Activity context data structure (640). Preferably, the Activity context data structure (640) is an OMG specified data structure. At xe2x80x9cBxe2x80x9d, the data structure (640) is implicitly propagated to a remote environment across a network (630). Implicit propagation means that the Activity Service executes the propagation with no extra work performed by the application. At xe2x80x9cCxe2x80x9d, an Activity Service Implementation in Process 2 unpacks the information in the data structure (640), in order for it to be utilised by Process 2 on thread 2.
The Activity Service is used by an application to group together a number of units of execution into a single, logical unit of work. The unit of work is preferably a CORBA Object Transaction Service (OTS) transaction or an activity. (CORBA is a registered trademark of OMG Inc.)
As part of the CORBA software structure, the OMG has set forth standards related to a transactions service. The transaction standards are known as the OTS. Further information can be found in xe2x80x9cCORBA Object Transaction Service Specification 1.1xe2x80x9d, available from http://www.omg.org. The standard specifies an interface to a set of transaction services with details of how the service should work and how the service should communicate the presence of the transaction between clients and servers.
Although the Activity Service currently provides useful functions for high-level services, the model also defines strict behaviour with regard to interactions between all activities and transactions when active on the same thread of execution, where an activity represents a context of a high-level service. That is, the current Activity Service model is tightly coupled to the concept of nesting between these components and for some high-level services, these strict interactions or inter-relations with other activities or transactions will not be appropriate.
Therefore, there is a need for an improved framework, whereby high-level services are not so tightly coupled to other components and there is more flexibility in structuring long-running applications and long-running transactional activities.
Accordingly, in a first aspect, the present invention provides a data processing system comprising: an object framework, and a plurality of components for supporting an application program utilising said plurality of components, said object framework further comprising: means for registering each of said plurality of components with said object framework; means, responsive to said means for registering, for associating each of said plurality of components with one of a plurality of context groups; in which each of said plurality of components comprises means for creating an instance of itself, in which a first instance is associated with a first context group of a first respective component and a second instance is associated with a second context group of a second respective component, in which said first instance and said second instance operate independently of each other.
Preferably, plurality of instances is associated with one context group. Preferably, an instance has an associated context and a plurality of associated contexts may be nested into a context hierarchy. Preferably, where a plurality of associated contexts are nested into a context hierarchy and are associated with one of a plurality of context groups, if a first of the plurality of associated contexts is suspended, then all further plurality of associated contexts are also suspended. Preferably, the further associated contexts are beneath the first associated context in the context hierarchy.
In a preferred embodiment, if the first associated context is resumed, the further associated contexts, which are beneath the first associated context in the context hierarchy, are also resumed. Preferably, in operation, one or more of the plurality of components is a service. Additionally, preferably in operation, one or more of the plurality of components is a transaction. Preferably, a unit of work represents one or more of the plurality of components.
In a preferred embodiment, one of the plurality of context groups is a default context group. Furthermore, preferably, the object framework is a CORBA Activity Service.
In a second aspect, the present invention provides, in a data processing system comprising: an object framework, and a plurality of components for supporting an application program utilising said plurality of components, a method of supporting such an application program, said method comprising the steps of: registering each of said plurality of components with said object framework; in response to said registering, associating each of said plurality of components with one of a plurality of context groups; in which said application program creates an instance of two or more of said plurality of components, in which a first instance is associated with a first context group of a first respective component and a second instance is associated with a second context group of a second respective component, in which said first instance and said second instance operate independently of each other.
In a third aspect, the present invention provides a computer program product for supporting an application program, running in a data processing system, said system comprising an object framework, and a plurality of components for supporting an application program utilising said plurality of components, said computer program product being stored on a computer readable storage medium and comprising instructions which when executed in said data processing system, carry out the steps of: registering each of said plurality of components with said object framework; in response to said registering, associating each of said plurality of components with one of a plurality of context groups; in which said application program creates an instance of two or more of said plurality of components, in which a first instance is associated with a first context group of a first respective component and a second instance is associated with a second context group of a second respective component, in which said first instance and said second instance operate independently of each other.